At its inception radio telephony was designed, and used for, voice communications. As the consumer electronics industry continued to mature, and the capabilities of processors increased, more devices became available to use wireless transfer of data and more applications became available that operate based on such transferred data. Of particular note are the Internet and local area networks (LANs). These two innovations allowed multiple users and multiple devices to communicate and exchange data between different devices and device types. With the advent of these devices and capabilities, users (both business and residential) found the need to transmit data, as well as voice, from mobile locations.
The infrastructure and networks which support this voice and data transfer have likewise evolved. Limited data applications, such as text messaging, were introduced into the so-called “2G” systems, such as the Global System for Mobile (GSM) communications. Packet data over radio communication systems became more usable in GSM with the addition of the General Packet Radio Services (GPRS). 3G systems and, then, even higher bandwidth radio communications introduced by Universal Terrestrial Radio Access (UTRA) standards made applications like surfing the web more easily accessible to millions of users.
Even as new network designs are rolled out by network manufacturers, future systems which provide greater data throughputs to end user devices are under discussion and development. For example, the so-called 3GPP Long Term Evolution (LTE) standardization project is intended to provide a technical basis for radio communications in the decades to come. All these new protocols are designed to support video communication between various hosts.
However, the hosts themselves need to be configured for supporting, for example, applications that need parameters measurable by a measurement tool, e.g., video communication, VoIP, gaming, interactive applications, etc. One aspect of these applications is the capability of the hosts to perform active end-to-end measurements to provide the needed parameters. The active end-to-end measurements are, for example, round-trip time (RTT), jitter, availability or available bandwidth between hosts in packet-switched networks. These measurements, i.e., the measured parameters, may be used by a wide range of network applications. In one application, such information may be used for optimizing file transfer performance between hosts or it can simply be used for monitoring a network path.
Conventionally, end-to-end network measurement methods require that both end-points (hosts) participate in the measurement. For example, end-to-end available bandwidth measurement methods such as BART (Ekelin et al., “Real-time measurement of end-to-end available bandwidth using Kalman filtering,” in Proceedings to the 10th IEEE/IFIP Network Operations and Management Symposium, Vancouver, Canada, April 2006, and S. Ekelin and M. Nilsson, “Using Filtering and Active Probing to Evaluate a Data Transfer Path,” U.S. patent application Ser. No. 11/285,723, the entire contents of which are incorporated here by reference), pathChirp (Ribeiro et al., “pathChirp: Efficient available bandwidth estimation for network paths,” in Proceedings of the Passive and Active Measurement Workshop, San Diego, 2003, the entire content of which is incorporated by reference), Pathload (M. Jain and C. Dovrolis, “Pathload: a measurement tool for end-to-end available bandwidth,” in Proceedings of the Passive and Active Measurement Workshop, Ft Collins, 2002, the entire content of which is incorporated by reference) and Spruce (Strauss et al., “A measurement study of available bandwidth estimation tools,” in Proceedings of the ACM SIGCOMM Internet Measurement Workshop, Miami, 2003, the entire content of which is incorporated by reference) require access to a sender node and a receiver node.
These methods rely on injecting UDP/IP (User Data Protocol) packets into the network path and measuring the relative change in inter-packet separation at the sender and receiver nodes. From this measurement, the available bandwidth between the nodes may be estimated by using various statistical analysis algorithms. Other common tools, such as ping, also require a sender node and a receiver node that have the appropriate software installed even though such methods already are implemented in the network stack.
Thus, when an application running on a first node needs one or more parameters related to the first node and the second node, both the first node and the second node need to have measurement software that enables the measurement of the parameters. If only the first node has the measurement software and the second node lacks that software, either the application would not be able to run on or the second node would request the user to download the measurement software. However, these approaches might be frustrating for the users. This scenario is illustrated in FIG. 1, in which a system 10 includes a node A 20, a node B 30 and a server 40. Node A 20 includes at least an application 22 and a measurement software MS 24. Node B 30 includes a corresponding application 32 but no corresponding measurement software.
Consider that applications 22 and 32 are related to video communication. When the user of Node A 20 launches application 22, this application performs some preparation work for establishing the video communication with Node B 30. Part of the preparation work is to establish the available bandwidth between Node A 20 and Node B 30. For determining the available bandwidth, the measurement software MS 24 needs to communicate with the counterpart measurement software at Node B 32. However, as discussed above, there are circumstances when Node B 32 either does not have the corresponding measurement software or does not have the same version of the MS. One solution for the application 22 is to inform the user of Node A 20 that a video communication may not be established with Node B. Another solution is for MS 24 to guess what the available bandwidth is and to use that value. However, this solution will result in a non-performant video communication between the nodes as, for example, when setting up an interactive video conference over the Internet the available bandwidth needs to be high enough while at the same time the latency should be as low as possible. Bad guesses of the path characteristics can be detrimental to the experienced video and audio quality.
Another solution, which is illustrated in FIG. 1, is to download at node B 30 the necessary measurement software MS 42 from server 40. Thus, the application 32 may request in step 34 the necessary software MS 42 from server 40 and may receive in step 36 the MS 42. Having the measurement software MS 42, applications 22 and 32 may complete the desired video communication.
However, this scenario requires the intervention of the user of Node B for downloading the MS software 42 from server 40 and supplemental communication exchanges between Node B and server 40. In addition, as the more advanced measurement techniques, such as those for measuring end-to-end available bandwidth, are developed over time and thus are being updated on a regular basis, both nodes would need the same software version to be able to utilize the measurement methods and thus, both nodes would eventually need to interact with server 40.
Accordingly, it would be desirable to provide devices, systems and methods that avoid the afore-described problems and drawbacks and are capable of performing the measurements even if one of the nodes does not have the measurement software.